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(57) Abstract 

A method of asynchronously transferring a plurality of 61es between client and host devices is provided. The method includes 
transmitting to a client device a plurality of identifiers for files and transferring between the host and client devices a data frame that 
includes an identifier and at least a portion of the corresponding file. Each identifier corresponds to a different one of the files to be 
transferred. The method also includes repeating the data frame transfers until the plurality of files has been transferred. 
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ASYNCHRONOUS DATA PROTOCOL 

TECHNICAL FIELD 

This invention relates to transferring data between a client and a host 
device using a network. 

5 BACKGROUND 

FIG. 1 illustrates a system 10 for transferring data, e.g., electronic mail 
messages, over a network 12. The system 10 provides for uploads and 
downloads of data frames between client devices 14, 16 and a host device 18. 
The client devices 14, 16 can be personal computers with network interfaces, 

10 e.g., modems 15, 17, and the network 12 can include a telephone line. The host 
device 18 includes a computer 20 and a storage device 22, e.g., one or more hard 
disks. The host computer 20 writes data uploaded from the client devices 14, 16 
to locations in the storage device 22 and reads data for downloads to the client 
devices 14, 16 from locations in the storage device 22. The host and client 

1 5 devices 18, 14, 16 transfer data using various known protocols. 

As used in this document, "uploads 1 ' and "downloads" refer to data 
transfers from the viewpoint of the host device 18. An upload transfers one or 
more data frames from a client device 14, 16 to the host device 18. A download 
transfers one or more data frames from the host device 18 to a client device 14, 

20 16. 

As used in this document, a frame, e.g., a data frame, is a separately 
transferred message on the network 12. 

FIGs. 2A and 2B show the formats 30, 40 of data frames that can be 
used by the system 10 of FIG. 1. Each data frame 30, 40 has segment for a 
25 token 32, 42 to indicate whether the frame is an upload or a download. Each 
data frame 30, 40 has a segment 34, 44 to identify the type of the client device 
14, 16. The client devices 14, 16 can be either of two types. The first type 
sends data frames with about 1 1 9 bytes of data, and the second type sends data 
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frames with about 1,000 bytes of data. Each data frame 30, 40 also has a 
segment 36, 46 for the data being transferred. The transferred data 36, 46 can be 
encoded to remove character string runs to minimize the length of the data. 

An upload or download of a file generally involves sending a sequence 
5 of data frames 30, 40 in which each member of the sequence contains a 

sequential portion of the data file being transferred. A transfer session starts with 
the transfer of the data frame 30, 40 for the first data portion of the file and ends 
with the transfer of the data frame 30, 40 for the last data portion of the file. 
The system 10 of FIG. 1 transfers one data file at a time between any particular 
10 client device 14, 16 and the host device 18. 

FIG. 3 illustrates how the host computer 20 stores uploaded data in the 
storage device 22. The host computer 20 converts the "TOKEN JJP" token in 
each uploaded frame to the download token, "TOKENDOWN". Then, the host 
computer 20 appends the converted frame 40 to a file 51 of the storage device 22 
15 assigned to the particular data transfer session. Each successive data frame of the 
session gets appended to the same file 51, i.e. data frames on lines 50, 52, 54 of 
the storage device 22. The host computer 20 uses a new file 55 to store the data 
frames 56, 57 for the next upload session, e.g, from a new client device 14, 16. 

To perform a download, for example, to a different client device 14, 
20 16 for which the uploaded data was intended, the host computer 20 sequentially 
reads the lines 50, 52, 54 for each converted data frame of the file being 
downloaded. The computer 20 sends, in the order read, each frame to the client 
device 14, 16 requesting the download. 

The host computer 20 uploads or downloads all data frames for a file 
25 during a single data transfer session. The host computer 20 will not start another 
upload or download for a client device 14, 16 until completing the present data 
transfer session for that client device 14, 16. Data transfers are constrained to 
relatively slow speeds, e.g., 28.8 kilobits per second or less, and to relatively 
small packet sizes so that the transfer does not overflow input buffers of the 
30 receiving device. 
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SUMMARY 

Different implementations of the invention may include various 
combinations of the following features. 

In a first aspect, a method of asynchronously transferring a plurality of 
5 data objects between client and host devices includes transmitting to a client 
device a plurality of identifiers for the data objects and transferring between the 
host and client devices a data frame that includes an identifier and at least a 
portion of the corresponding data object. Each identifier corresponds to a 
different one of the data objects to be transferred. The method also includes 
10 repeating the data frame transfers until the plurality of data objects has been 
transferred. 

In a second aspect, a method of asynchronously transferring Ha^ 
between host and client devices includes receiving from a client device a frame to 
request a data transfer session; sending to the client device a frame defining a 

15 session protocol that assigns an identifier to each data object; and transferring a 
plurality of data frames between the client and host devices. Each data frame 
includes a data packet containing a portion of a data object and an identifier 
assigned to the data object. 

In a third aspect, a method of asynchronously transferring a plurality 

20 of data objects between client and host devices includes transmitting to a client 
device a plurality of identifiers and routings of one or more handling processes, 
transferring between the client and host devices first and second data frames, and 
repeating the data frame transfers until the plurality of files have been transferred. 
Each identifier corresponds to one of the files. The. first data .frame includes a 

25 first identifier, a routing of a first handling process, and at least a portion of the 
file corresponding to the first identifier. The second data frame includes a 
second identifier, a routing of a second handling process, and at least a portion of 
the file corresponding to the second identifier. 

In a fourth aspect, a method for transmitting data over a network 

30 between host and client devices includes receiving from a client device a frame 
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requesting either a data upload session or a data download session, establishing a 
session protocol in response to receiving the frame, and transmitting to the client 
device a frame defining the session protocol. The method also includes receiving 
from the client device a data frame conforming to the protocol if the frame from 
5 the client device requested an upload, and transmitting to the client device a data 
frame conforming to the protocol if the frame from the client device requested a 
download. 

In a fifth aspect, media arc encoded with programs, executable by a 
machine, for performing one or more of the above-described methods. 

10 The methods, techniques, and systems described here may provide one 

or more of the following advantages. 

One advantage is that a client device may transfer data frames for 
different objects and/or for different transfer sessions either sequential or in an 
interleaved fashion. For example, a client can interleave data frames for uploads 

15 and downloads. 

Another advantage is that the host and client devices use handshaking. 
Thus, a receiving device can throttle data transfers by not sending a handshake 
signal, i.e. a request for more data frames. Handshaking provides a tool the 
receiving device to avoid overflows in input buffers. Similarly, either the 

20 receiving or sending device can terminate a session by sending an abort 

command. The abort command device can provide a method for dealing with 
errors. 

Finally, the host device has more control over the data transfer session. 
For example, the host device may assign the handling of different data objects- to 
25 different host processes. The host device can also fix the size of data frames and 
the frame count either to accommodate a lack of host resources or to more 
efficiently use available host resources. 

Other features and advantages will be apparent from the following 
description, including the drawings and the claims. 
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DESCRIPTION OF DRAWINGS 

FIG. 1 shows a prior art system for transferring data between host and 
client devices using a network; 

FIGs. 2 A shows the format of a data frame for uploading data from 
5 the client devices in the system shown in FIG. I; 

FIG. 2B shows the format of a data frame for downloading data from 
the host device in the system shown in FIG. 1; 

FIG. 3 illustrates how the storage device of the host device, shown in 
FIG. 1, stores a data file for later downloads; 
10 FIG. 4 shows an embodiment of a system for transferring data objects 

between host and client devices using a network; 

FIG. 5 A and 5B. are flowcharts illustrating a method for transferring 
data objects over a network; 

FIG. 6A shows a frame format, which a client device uses to request a 
15 data transfer session; 

FIG. 6B shows a frame format, which the host device uses to establish 
a session protocol; 

FIG. 7 is a flowchart illustrating a method for a host device to transfer 

data; 

20 FIG. 8A and 8B are flowcharts illustrating methods for transmitting 

and receiving data frames; 

FIG. 8C is a flowchart illustrating a command to terminate an entire 
data transfer session; 

FIG. 9A shows a format of a data frame used to transfer portions of 
25 data objects; 

FIG. 9B shows a format of a data frame used to indicate the last data 
of a data object; 

FIG. 9C shows the format of the frame used to request more data in 
the methods shown in FIGs. 8 A and 8B; 
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FIG. 9D shows a format of a frame that either the client or host device 
can send to abort the session in FIG. 8C; and 

FIG. 10 illustrates a method by which the host device may change the 
size of data frames and/or the frame count dynamically. 

5 DETAILED DESCRIPTION 

FIG. 4 shows a system 100 for transferring digital data asynchronously 
between a host device 1 02 and one or more client devices 1 04, 1 06. Each data 
transfer is either an upload or a download, which involves a single client device 
104, 106. The client devices 104, 1.06 may be personal computers or other 

10 hardware devices. A network 108 facilitates the transfers. The host and client 
devices 102, 104, 106 each have a network address and a network interface. 

The network 108 may have a variety of forms. For example, the 
network 108 can be a local area network, a wide area network, the internet, or a 
similar device. The network may include an analog portion, e.g., a plain old 

15 telephone system, and/or a digital portion, e.g., an ISDN network. The devices 
104, 106, 102 may use modems or other devices to convert digital data into 
forms transferable by the network 108. The network 108 may use a variety of 
protocols, e.g., the P3 protocol, and may envelop the frames used to transfer data. 
The network 108 can transfer digital frames and can support duplexed 

20 communications between the host and client devices 102, 104, 106. 

The host device 102 includes at least one host computer 112 and a 
storage device 113 having a plurality of storage volumes or files 114, 116, 118. 
The storage device 113 may include one, or more magnetic hard disks or BAM 
disks (both not shown). The host computer 1 12 can read from and write to the 

25 storage volumes 114, 116, 118 through a local network 122, e.g., a dedicated 

data bus. A client handler 120 interfaces the network 108 to receive frames from 
the client devices 104, 106 and to send frames to the client devices 104, 106. 
The client handler 120 may be a program, hardware, or a combination of both. 
The client handler 120 transfers frames between the network 108 and one or 
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more software processes or servers X, Y, NC of the host computer 120. The 
processes or servers handle communications with the client devices 104, 106. 

The host computer 102 has two types of processes (or programs): (1) a 
network communications (NC) process, and (2) handling processes X, Y. The 
5 NC process selects one or more of the handling processes X, Y, i.e. programs, in 
response to receiving a request from a client device 104, 106 for a data transfer 
session. The handling processes X, Y control and manage the transfers of data 
frames and the establishment of a protocol for the data transfer session. 

The host computer 1 02 may have several copies of each process X, Y 

10 for handling data transfer sessions. 

New requests from the client devices 104, 106 are forwarded to the 
NC process by the client handler 120. The NC process may select a handling 
process X, Y based on a variety of factors. The factors can include the data 
object to be transferred, the type of transfer to be performed, e.g., image 

15 upload/download, audio upload/download, etc., and/or on the availability of the 
various handling processes X, Y. For example, the NC process may select the 
process X to handle the data frames for the first image of the session and select 
the process Y to handle data frames for the second image of the transfer session. 
The handling processes X, Y control the session after being selected. The 

20 selected handling processes X, Y access the storage volumes 1 14-1 18 to perform 
uploads and downloads. The client handler 120 directs all subsequent frames for 
the data transfer session to the selected handling processes X, Y. 

FIG. 4 shows that the host computer 112 can execute the programs X, 
Y, and NC from a main memory 124 or from another medium 125 readable by a 

25 drive 126 of the host computer 1 12. The medium 125 may be a magnetic disk 
or tape, an optical disk, or any other device or article of manufacture suitable for 
storing software programs in a form executable by the host computer 112. 

FIGs. 5 A and 5B are flowcharts illustrating methods 130, 140 by 
which the respective client and host devices 104, 106, 102 transfer data objects 

30 over the network 108 using an asynchronous data protocol. 
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Referring to FIG. 5 A, a client device 104, 106 initiates all data transfer 
sessions, i.e. both uploads and downloads. To initiate a data transfer session, the 
client device 104, 106 sends a frame to the host computer 1 12 to request the 
session (step 132). Then, the client device 104, 106 waits for a response from 
5 the host device 102. In response to the request, the client device 104, 106 

receives a frame from the host device 102, which defines a protocol for the data 
transfer session (step 134). The session protocol gives a size for data frames, a 
frame count, a unique identifier for each data object, a routing for the process X, 
. Y handling each data object, and commands to control the session. The routing 
10 identifies a handling process X, Y, e.g., by a memory address or by an 

identifying token, to the client handler 120. After receiving the frame with the 
session protocol, the client device 104, 106 participates in the actual transfer of a 
plurality of data frames, i.e. uploading or downloading the frames as the case 
may be (step 136). The client device 104, 106 sets up a data transfer session and 
15 then participates in the transfer of data frames, the data frames including the data 
packets being transferred. 

The "frame count" refers to the number of successive data frames that 
one of the devices 102, 104, 106 can send without receiving a request frame for 
more data from the device 102, 104, 106 receiving the data frames. The request 
20 frame for more data implements one type of handshaking between the sender and 
. receiver of data frames. The receiver can stop the sender from transmitting 
another group or "frame count 11 of data frames by not handshaking, i.e. by not 
. sending the frame requesting more data. This handshaking enables the receiving 
device to throttle data transmission. Nevertheless, a device 102, 104, 106 still 
25 may send a number of data frames, i.e. the value of the "frame count", without 
receiving a handshake from the receiving device. 

Referring to FIG. 4, the client device 104 has a program "DP* with 
instructions to execute the method of FIG. 5 A. The client device 104 can 
execute the program "DT* from a main memory 127 or from another medium 
30 128 readable by a drive 129 of the client device 104. The medium 128 may be a 
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magnetic disk or tape, an optical disk, or another device or article of manufacture 
suitable for storing software programs in a form executable by the client device 
104. . 

Referring to FIG. 5B, the host device 102 establishes a session 
5 protocol and then participates in the data transfers. The host device 102 receives 
the frame to request a data transfer session from the client device 104, 106 (step 
142). In response to receiving the request, the host computer 112 allocates host 
resources for the data transfer session (step 144). The request from the client 
device 104, 106, includes information, which the host computer 112 uses to 

10 allocate host resources for the session. After allocating its resources, the host 
computer 112 sends a frame to the client device 104, 106 to establish a session 
protocol (step 1 46). Then, the host device 1 02 participates in the transfer of data 
frames, which include the data packets being transferred, between the client 
device 104, 106 and itself (step 148). Both uploads and downloads start by 

15 establishing a session protocol and then transferring data frames. 

Referring to FIG. 4, the programs X, Y, and NC include instructions 
for performing the method 140 illustrated in FIG. 5B. 

FIG. 6 A shows one format for the frame 210 that a client device 104, 
106 sends to request a data transfer session in FIG. 5 A. The frame 210 has a 

20 plurality of segments 214-218 distinguished either by their position in the frame 
or by preselected start sequences. The first segment 214 indicates the type of 
transfer. Hie system 100 supports a preselected set of transfer types. In some 
embodiments, the transfer types are generic uploads and generic downloads. In 
other embodiments, the transfer types are more specialized uploads and 

25 downloads, e.g., for an image, an audio file, a library data base, etc. The second 
segment 215 indicates the number of data objects. The different data objects 
may include text data, image data, multimedia data, audio data, video data, etc. 
The client device 104, 106 decides which portions of a multi-file object will be 
different "data objects." A text file with four imbedded images could have one 

30 data object for each of the imbedded images. The handling process X, Y assigns 
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to each data object a unique identifier and an associated storage volume 114, 116, 
118. Different data objects may be subsequently transferred independently by the 
system 108. The next segments 216, 217, 218 of the frame 210 identify each 
data object. The frame 210 for requesting a data transfer session identifies the 
5 transfer type and the data objects to transfer. 

FIG. 6B shows one format for the frame 220 that the host device 102 
sends to establish the session protocol in FIG. 5B. The frame 220 has a plurality 
of ordered segments 221-228. The first segment 221 identifies the transfer type 
of the session. The transfer type is an echo of the type requested by the client 
10 device 104, 106 in frame 210 of FIG. 6A. The second segment 222 identifies 
the routings for the processes X, Y assigned to handle the data objects of the 
session. From the routing, the client handler 120 can determine which handling 
process X, Y should get a frame subsequently received from the network 108. 
The third segment 223 defines the size of data frames for this session. The 
15 fourth segment 224 defines the frame count for the session. The fifth segment 
225 defines the format of an abort command that either the sender or receiver 
can use to abort the entire data transfer session. The next segments 226-228 list 
the unique identifiers assigned to each data object of the session. 

Depending on the implementation, the format of the frame 220 for 
20 establishing a protocol for a "download" session does not need to include 
. segments for the size of data frames or for the frame count. Since the host 
computer 102 is transmitting the data frames in a "download", it is unnecessary 
. to inform the client device 104, 106 the values of these parameters. 

FIG. 7 is a flowchart for a method 160 by which the host device 102 
25 transfers data according to the method 140 of FIG. 5B. A session begins when 
the client handler 120 receives the request frame 210 shown in FIG. 6 A (step 
161). The client handler 120 sends the request frame to the host computer 112 
for handling by the network communications (NC) process, e.g., a program for 
routing electronic mail (step 162). The NC process assigns the request frame to 
30 one or more of processes X, Y of the host computer 1 12 (step 163) for handling. 
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The handling processes X, Y manage the remainder of the data 
transfer session. First, each handling process X, Y assigns a unique storage 
volume 1 14, 116, 1 18 to the data object that it has been assigned to handle by 
the NC process (step 164). To assign a storage volume, each handling process X, 
5 Y makes a list in which each entry includes one of the unique identifiers, an 
associated storage volume 114, 116. 118 and an associated data object. The 
identifier is unique among the set of identifiers for all data objects, all active 
sessions, and all inactive sessions for which accessible data remains in the storage 
volumes 1 14, 1 16, 118. Second, the handling processes X, Y fix the session 
10 transfer parameters such as the size of data frames and the frame count (step 
165). 

The host computer 112 assigns values to the transfer parameters based 
on the availability of host resources. The use of host resources is partially 

c ontrollable throu g h the values of the transfer parameters . For example, a frame 

15 count of one allows the client device 104, 106 to send only one more data frame 
in response to a request for more data from the host device 1 02. Thus, the host 
device 102 can stop the stream of data at any time. Similarly, a small size for 
data frames reduces the amount of space occupied in input buffers (not shown) of 
the client handler 120 during an upload. Finally, assigning larger values to the 

20 frame count and/or size for data frames enables the client devices 104, 106 with 
active data transfer sessions to use more of the host resources, i.e. to efficiently 
use available bandwidth of the host device 102. 

The host device 102 sends a frame for establishing the session protocol 
to the client device 104, 106, which requested- the. session4step 166). The frame 

25 for establishing the protocol has the format 220 shown in FIG. 6B. Finally, the 
host device 102 receives a plurality of data frames from the client device 104, 
106 (step 167). 

FIGs. 8 A and 8B illustrate methods 170, 190 for transferring data 
frames according to steps 136, 148 of the methods 130, 140 of FIGs. 5A and 5B. 
30 FIG. 8 A shows a method 170 used by a data sender, i.e. the host device 102 for 



- 15:26:14 



WO 99/34555 



PCT/US98/27268 



- 12 - 

a download and a client device 104, 106 for an upload. FIG. 8B illustrates the 
method 190 used by a data receiver, i.e. the host device 102 for an upload and a 
client devices 104, 106 for a download. 

Referring first to FIG. 8A, a data sender transmits a sequence of up to 
5 N data frames for data portions of N selected data objects, N being the frame 
count (steps 172, 174, and 176). The various data frames 172, 174, 176 may 
contain data belonging to different data objects. After sending each data frame, 
the data sender determines whether data remains to send (steps 173 and 175). If 
data remains to send, the data sender proceeds to the next step of sending a data 
10 frame (steps 174 and 176). If data does not remain to send, the program 

controlling the sending of data frames releases control to other programs so that 
the sender can perform activities not related to sending data frames (steps 177 
and 1 79). If no data remains to send, the data sender also terminates the session 
by sending to the data receiver a frame announcing that no more data remains 
15 (steps 177 and 179). 

After sending a frame count of N data frames, the data sender 
determines whether a frame requesting more data has been received from the data 
receiver (step 1 78). If the data sender has not received the frame requesting 
more data, the data sender releases control to other processes of the sender (step 
20 180). If the data sender has received a frame requesting more data frames, the 

data sender sends the data frames for the next frame count (step 1 84). If the data 

sender receives the request for more data at a later time, it will start sending the 
next frame count of data frames (not shown) at that time. The frame count or 
number of successive data frames 172, 174, 176. that the sender sends without 
25 waiting is determined by the session protocol. 

FIG. 8B shows a method 190 by which a data receiver receives data 
frames that were sent according to the method 170 of FIG. 8 A. The data 
receiver receives the first data frame sent in step 172 of FIG. 8 A (step 191). 
Each data frame has protocol information and a data packet. The protocol 
30 information includes a routing, which identifies the handling process X, Y, and a 
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unique identifier for a data object. The handling process X, Y uses the unique 
identifier to determine which storage volume 114, 116, 118 is assigned to the 
data object. The handling process X, Y writes or appends the data packet from 
the data frame to the storage volume 114, 116, 118 determined from the unique 
5 identifier (step 1 92). Next, the data receiver receives the second data frame 
associated with the second selected data object from step 1 74 of FIG. 8 A (step 
193). The data receiver uses the unique identifier from the second data frame to 
write or append the second data packet therein to the storage volume 114, 116, 
118 assigned to the second selected data object (step 194). The data receiver 

10 repeats steps 193 and 194 for successively received data frames (not shown). 

The data receiver writes or appends data frames for data from a data 
object to a storage volume 114, 116. 1 1 8 in a sequential fashion. The receiver 
writes or appends earlier sent data frames to the assigned storage 1 14, 1 16, 118, 
for a data object, before appending later sent data frames for the same data 

15 object. Writes of data packets for the same data object are in the order sent. Of 
course, the data receiver need not write data frames for different data objects to 
the storage volumes 1 14, 1 16, 118 in the order sent 

After receiving a preselected number of data frames, the data receiver 
determines whether resources are available to receive another frame count of data 

20 frames (step 195). If resources are available, the receiver sends a frame 

requesting more data to the data sender (step 196). Then, the receiver continues 
receiving and writing data packets from received data frames to the storage 
volumes 114, 116 ,118 using the unique identifiers provided by the data frames 
themselves (steps 197 and 198i). If the data receiver sends a frame requesting 

25 more data at step 197, the data receiver will receive the next frame count of data 
frames from the data sender and will repeat steps 192-197 (loop 199). Thus, the 
data receiver receives the next frame count only if it sends a frame requesting 
more data. In other words, data is transferred between the sender and receiver 
using handshaking. 
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FIG. 8C illustrates a method 200 of aborting a data transfer session, 
which has been established at step 134, 146 of FIGs. 5A and 5B. A first device 
for the data transfer session, i.e. either the data receiver or sender, sends to the 
second device for the session, i.e. the data sender or receiver, respectively, a 
5 frame with an abort command (step 202). The second device receives the frame 
with the abort command (step 204). In response to receiving the abort request, 
the second device stops processing data frames for the data transfer session 
indicated in the frame with the abort command (step 206). The device receiving 
the frame to abort returns control to other programs and processes therein. 
10 Both the host device 102 and the client device 104, 106 can terminate 

an entire data transfer session with an abort command. The abort or termination 
of an entire session is a second type of "handshaking" between host and client 
devices 102, 104, 106. 

FIG. 9A shows one format 240 for data frames according to the 
15 methods 130, 140, 170, 190 of FIGs. 5A-5B and 8A-8B. Each data frame 240 
has a plurality of segments 242-244 for types of information mandated by the 
session protocol. A first segment 242 identifies the transmission type, i.e. upload 
and download or another type discussed above. A second segment 243 identifies 
the routing of the process X, Y handling this data object. A third segment 244 
20 gives the unique identifier associated with the data object being transferred. 
-~ From to e unique identifier, the host device 102 can determine where to store data 
portion being uploaded, and the client device 104, 106 can determine what to do 
r with data portion being downloaded. The remaining segment 245 contain the 

data portion or packet being transferred Each data frame 240 includes a data 

25 portion and identifies the transfer type, routing of the process X, Y handling the 
data object, and the storage identifier for the data object being transferred. 

FIG. 9B shows the format of a data frame 247 for signaling the last 
data for a data object of the data transfer session. The first three segments of the 
frame 247 have the same format as in other data frames 240 shown in FIG. 9A. 
30 The last segment 248 of the frame 247 includes both the remaining data portion 
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of the data object being transferred and a command sequence. The command 
sequence indicates that the data of this frame is the last data of the session for the 
identified data object. The handling process X, Y of the host computer 1 1 2 and 
the data transfer program "DT" of the client device 104 terminate the session 
5 with respect to this data object in response to receiving the command for the last 
data. Any of the data frames in steps 172, 174, 176 and 191-194, 197-198 in 
FIGs. 8A and 8B can be a frame for last data-signaling the completion of the 
transfer of one data object. 

FIG. 9C shows the format for a frame 250 for requesting more data, 
10 i.e. the handshake from the data receiver. The frame for requesting more data 
250 has segments 252, 253, 254, for a transfer type, a routing of a handling 
process X, Y, and a unique identifier analogous to the segments 242, 243, 244 of 
the data frame 240 shown in FIG. 9 A. The last segment 255 of the frame 250 is 
a command sequence to request the next frame count of data frames. 
15 FIG. 9D shows the format of an abort frame 260 used by the method 

200 of FIG. 8C. The first three segments of the abort format are analogous to 
those of the frame 250 for requesting more data, which is shown in FIG. 9C. 
The last segment 262 of the abort frame 260 contains a command sequence to 
abort the entire data transfer session. Either the host or client devices 102, 104, 
20 106 can transmit an abort frame at any step of FIGs. 8A and 8B. 

FIG. 10 illustrates a method 270 by which the host device 102 may 
change the routing, the size of data frames, and/or the frame count dynamically. 
To implement such a change, the host device 102 redetermines the available host 
resources (272). The host device 102 determines the values of the new routing, 
25 size of data frames and/or frame count (step 274). Then, the host device 102 
sends a frame to the client device 104, 106 to establish a new protocol for the 
session (step 276). The new frame indicates the original transfer type, routing, 
and unique identifiers and also indicates the new routing, size of data frames, 
and/or frame count The client device 104, 106 uses the new routing, size for 
30 data frames and frame count in response to receiving the frame for the new 
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protocol from the host device 102 (step 278). The host device 102 may 
dynamically change the routing, the size of data frames and/or the frame count to 
more efficiently use available host resources or to reduce the risk of overloading 
the host's input buffers. 
5 In some embodiments the routing 222, 243, 253 may be the actual 

address, in the memory 124, for the handling process X, Y assigned to a 
particular data object. 

In some embodiments, the format of the data frames 240 and last data 
of a type frames 247 for a "download" session do not include segments for the 
10 size of data frames or for the routings of handling processes X, Y. 

The client devices 104, 106 of FIG. 4 can interleave sending frames 
for different data objects, because each frame includes a unique identifier and a 
routing. The client handler 120 keeps a list of routings for the handling 
processes X, Y 114, 1 16, 1 18 assigned to each data transfer session. The client 
15 handler 120 uses the list to route data and control frames for different data 

objects and sessions to the proper processes X, Y. The handling processes X, Y 
use the unique identifier to determine the storage volume 114, 116, 118 assigned 
for storage of data from each frame. Since the handling of data frames does not 
depend on the order received, the client device 104, 106 can upload data frames 
20 in any convenient manner, e.g., by interleaving data frames for different data 
. : . objects or for different sessions. 

Similarly, the host device 102 of FIG. 4 can interleave sending data 
* c frames for the various data objects of a download session. The client device 104, 
106 uniquely identifies received data frames by the same unique identifier, which 
25 enabled the host device 102 to identify data portions of the different data objects. 
Once the client device 104, 106 knows the data object, it knows what to do with 
the data. The order of delivery is not needed to identify the data object or data 
transfer session for a downloaded data frame. 

In one embodiment, the host device 1 02 interleaves the transfer of the 
30 data objects for the different image objects imbedded in text. In this 
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embodiment, the client device 104, 106 receives coarse grained forms of each 
image embedded in the text object substantially simultaneously. As the transfer 
continues each of the images becomes clearer at a uniform rate. This 
embodiment enables a client to view all of the embedded images, at least coarse 
versions of all images, before the entire download completes. 

Similarly, both the client devices 104, 106 and the host device 102 can 
interleave sending data frames for different data transfer sessions. Each data 
frame has a unique identifier for the data object to which the data portion therein 
belongs and a routing for a handling process X, Y. The routing enables the 
client handler 120 to recognize the session's handling processes X, Y. The 
unique identifier enables the handling processes X, Y to determine the session's 
storage volumes 114, 116, 118. The unique identifiers also enahle the client 
devices 104, 106 to recognize the session to which a received data frame belongs. 
Arrival order of data frames is inessential to recognizing the data transfer session 
to which the data frames belong. 

The techniques and methods may be implemented in computer 
hardware or software, or a combination of the two. However, the techniques are 
not limited to any particular hardware or software configuration. Instead, they 
may find applicability in any computing or processing environment for 
transferring data between client and host devices. Preferably, the techniques are 
implemented in computer programs executing on programmable computers that 
each include a processor, storage medium readable by the processor (including 
volatile and no n- volatile memory and/or storage elements), at least one input 
device, and one or more output devices. Program code npf-rat^ on data^ eatered 
using the input device to perform the functions described and to generate output 
information. The output information is applied to the one or more output 
devices. 

Each program is preferably implemented in a high level procedural or 
object oriented prograrnming language to communicate with a computer system. 
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However, the programs can be implemented in assembly or machine language, if 
desired. In any case, the language may be a complied or interpreted language. 

Preferably a storage medium or device (e.g., CD-ROM, hard disk or 
magnetic diskette) stores each such program. The storage medium or device is 
5 readable by a general or special purpose programmable computer to configure 
and operate the computer to perform the methods described in this document 
when read by the computer. The system may also be considered to be 
implemented as a computer-readable storage medium, configured with a computer 
program, where the storage medium so configured causes a computer to operate 
10 in a specific and predefined manner. 

Other embodiments are within the scope of the following claims. 
What is claimed is: 
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1. A method of asynchronously transferring a plurality of data 
objects between client and host devices, the method comprising: 

transmitting to a client device a plurality of identifiers for data objects, 
each identifier corresponding to a different one of the data objects to be 
5 transferred; 

transferring over a network between the host and ciient devices a data 
frame that includes an identifier and at least a portion of the corresponding data 
object; and 

repeating the data frame transfers until the plurality of data objects 
10 have been transferred. 

2. The method of claim 1, wherein at least two sequential transfers 
of a data frame include transferring frames with different identifiers. 

3. The method of claim 1, wherein the transfers of the portions of 
at least two data objects are interleaved. 

15 4. The method of claim 1, further comprising: 

transmitting a data transfer request from the client device to the host 
device, the transmission of a plurality of identifiers being in response to the data 
transfer request. 

5. The method of claim 1, wherein the transfers are downloads. 

20 6. The method of claim 1, wherein a portion of the transfers are 

uploads and a portion of the transfers are downloads, the uploads and downloads 
being interleaved. 
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7. The method of claim 1, wherein the transfers of data frames 
stop at a preselected frame count in the absence of a request for more data 
frames from a device that receives the data frames. 

8. The method of claim 1 , further comprising: 

5 transmitting to the client device a size for data frames before the 

transfers, the data frames transferred being of said size. 

9. The method of claim 1, further comprising: 
transmitting a frame count to the client device, the frame count 

corresponding to the number of data frames that the client device can transfer 
10 without receiving a request for more data frames. 

10. A method of asynchronously transferring a plurality of data 
objects between client and host devices, the method comprising: 

transmitting to a client device a plurality of identifiers and routings of 
one or more handling processes, each identifier corresponding to one of the data 
15 objects; 

transferring between the client and host devices a first data frame that 
includes a first identifier, a routing of a first handling process, and at least a 
portion of the data object corresponding to the first identifier; 

transferring between the client and host devices a second data frame 
20 that includes a second identifier, a routing of a second handling process, and at 
least a portion of the data object corresponding to the second identifier,, and 

repeating the data frame transfers until the plurality of data objects 
have been transferred. 
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11. The method of claim 10, further comprising: 

writing the portions of the data objects to first and second storage 
locations to which the respective first and second identifiers are assigned. 

12. The method of claim 1 1, wherein the writes of the first and 
5 second portions of the data objects corresponding to the first and second 

identifiers are controlled by the first and second handling processes, respectively. 

13. The method of claim 10, wherein the first and second handling 
processes handle uploads of data objects for first and second data objects, 
respectively. 

10 14. The method of claim 13, wherein the first and second data 

objects include data for first and second images, respectively. 

15. The method of claim 10, wherein the transfers of data frames 
including the first identifier stop at a preselected frame count in the absence of a 
request for more data frames from a device that receives the data frames. 

15 16. The method of claim 10, wherein the request for more data 

frames includes the routing of the first handling process. 
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17. A method of asynchronously transferring data between host and 
client devices, comprising: 

receiving from a client device a frame requesting a data transfer 

session; 

5 sending to the client device a frame defining a session protocol that 

assigns an identifier to each data object; and 

transferring a plurality of data frames between the client and host 
devices, each data frame comprising a data portion of a data object and an 
identifier assigned to the data object including said data portion. 

10 18. The method of claim 17, wherein the transferring of data 

frames includes a data upload. 

19. The method of claim 18, further comprising: 

writing a particular data portion to a storage volume assigned to a 
particular identifier in response to receiving a data frame including the particular 
15 identifier and data portion, unique data objects being assigned to each storage 
volume. 

20. The method of claim 17, further comprising: 

receiving a second frame from the client device requesting a second 
data transfer session; 

20: sending a second frame to the client device defining a second session 

protocol that assigns an identifier to each data object of the second wggin n - 

transferring a plurality of second data frames between the client and 
host devices, each second data frame including a second data portion and an 
identifier assigned to a data object including the second data portion. 
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21. The method of claim 20, wherein the transfers of first and 
second data frames are interleaved. 

22. The method of claim 20, wherein the transfers of second data 
frames are downloads from the host device. 



receiving a frame from a second client device requesting a second data 
transfer session; 

sending a frame to the second client device defining a second session 
protocol that assigns an identifier to each second data object of the second 
10 session; and 

transferring a plurality of second data frames between the second client 
and host devices, each second data frame including a second data portion of a 
second data object and an associated identifier. 



to each data object; and 

wherein each data frame includes the routing of the handling program 
assigned to the data object therein. 

25. The method of claim 24, wherein first and second data objects 
20 are assigned first and second handling programs, respectively. 



5 



23. The method of claim 17, further comprising: 



15 



24. The method of claim 17, further comprising: 

sending to the client device a routing for a handling program assigned 
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26. The method of claim 24, further comprising: 

writing a particular data portion to a storage volume assigned to a 
particular identifier in response to receiving a data frame including the particular 
identifier and data portion, unique data objects being assigned to each storage 
5 volume. 

27. The method of claim 26, further comprising: 

controlling the write with the handling program assigned to the data 
object being written. 

28. A method for transmitting data over a network between host 
1 0 and client devices, the method comprising: 

receiving from a client device a frame requesting one of a data upload 
session and a data download session; 

establishing a session protocol in response to receiving the frame from 
the client device; 

15 transmitting to the client device a frame defining the session protocol; 

receiving from the client device a data frame conforming to the 
protocol if the frame from the client device requested an upload; and 

transmitting to the client device a data frame conforming to the 
r protocol if the frame from the client device requested a download. 

20 29. The method of claim 28, wherein the establishing a session 

protocol includes: 

assigning a handling program and a storage location to each data 
object identified in the frame requesting a session; and 

wherein the transmitting to the client device a frame defining the 
25 session protocol includes sending an identifier for the storage location and a 
routing for the handling program assigned to each data object. 
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30. The method of claim 28, wherein the transmission of a frame 
defining the session protocol includes: 

transmitting a size for data frames to the client device. 

31. The method of claim 28, wherein the transmission of a frame 
defining a session protocol includes transmitting a frame count, the frame count 
being the number of data frames that the client can send prior to receiving a 
request for more data. 

32. The method of claim 28, 

wherein the transmission of a frame defining a session protocol 
includes transmitting a format for a command to abort to the client device; and 

further comprising terminating the session in response to receiving the 
command to abort from the client device. 

33. The method of claim 28, wherein the transmission of a data 
frame comprises: 

receiving a frame including an identifier for a storage location, a 
routing of a handling program, and data to store in the identified storage location; 
and 

wherein the transmission of a session protocol includes transmitting to 
the client device the identifier and the routing of the handling program assigned 
to each data object of the session. 
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34. The method of claim 28, wherein the act of transmitting a data 
frame further comprises: 

receiving a second message including a second identifier for a second 
storage location and data to store in the second storage location; and 
5 wherein the transmitting a frame defining the session protocol includes 

transmitting the second identifier to the client device. 

35. The method of claim 28, where in the act of establishing 
includes assigning a storage location and associated identifier to each data object 
identified in the frame requesting a session. 

10 36 « The method of claim 35, wherein the data objects comprise: 

a first image file; and 
a second image file. 



37. A computer readable medium encoding a program of 
instructions to asynchronously transfer a plurality of data objects between client 
15 and host devices, the instructions comprising: 

transmit to a client device a plurality of identifiers for data objects, 
each identifier corresponding to a different one of the data objects to be 
transferred; 

transfer over a network between the host and client devices a data 
20- frame that includes an identifier and at least a portion of the corresponding data 
object; and 

repeat the data frame transfers until the plurality of data objects have 
been transferred. 
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38. The computer readable medium of claim 37, wherein at least 
two sequential transfers of a data frame include transfers of frames with different 
identifiers. 



39. The computer readable medium of claim 37, wherein the 
5 transfers of the portions of at least two data objects are interleaved. 

40. The computer readable medium of claim 37, the instructions 
further comprising: 

transmit a data transfer request from the client device to the host 
device, the transmission of a plurality of identifiers being in response to the data 
10 transfer request 

41. The computer readable medium of claim 37, wherein the 
transfers are downloads. 

42. The computer readable medium of claim 37, wherein a portion 
of the transfers are uploads and a portion of the transfers are downloads, the 

15 uploads and downloads being interleaved. 

43. The computer readable medium of claim 37, wherein the 
transfers of data frames stop at a preselected frame count in the absence of a 
request for more data frames from a device that receives the data frames. 

44. The computer readable medium of claim 37, the instructions 
20 further comprising: 

transmit a frame count to the client device, the frame count 
corresponding to the number of data frames that the client device can transfer 
without receiving a request for more data frames. 
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45. A computer readable medium encoding a program of 
instructions to asynchronously transfer a plurality of data objects between client 
and host devices, the instructions comprising: 

transmit to a client device a plurality of identifiers and routings of one, 
5 or more handling processes, each identifier corresponding to one of the data 
objects; 

transfer between the client and host devices a first data frame that 
includes a first identifier, a routing of a first handling process, and at least a 
.. portion of the data object corresponding to the first identifier; 
10 transfer between the client and host devices a second data frame that 

includes a second identifier, a routing of a second handling process, and at least a 
portion of the data object corresponding to the second identifier, and 

repeat the data frame transfers until the plurality of data objects have 
been transferred. 



15 46. The computer readable medium of claim 45, the instructions 

further comprising: 

write the portions of the data objects to first and second storage 
locations to which the respective first and second identifiers are assigned. 

47. The computer readable medium of claim 46, wherein the writes 
20 of the first and second portions of the data objects corresponding to the first and 

second identifiers are controlled by the first and second handling processes, 
respectively. 

48. The computer readable medium of claim 45, wherein the first 
and second processes handle uploads of files for first and second data objects. 
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49. The computer readable medium of claim 48, wherein the first 
and second data objects are data for first and second images, respectively. 

50. The computer readable medium of claim 45, wherein the 
transfers of data frames including the first identifier stop at a preselected frame 

5 count in the absence of a request for more data frames from a device that 
receives the data frames. 



51. A computer readable medium encoding a program of 
instructions to asynchronously transferring data between host and client devices, 
the instructions comprising: 
10 receive from a client, device a frame requesting a data transfer session; 

send to the client device a frame defining a session protocol that 
assigns an identifier to each data object of the session; and 

transfer a plurality of data frames between the client and host devices, 
each data frame comprising a data portion and an identifier assigned to a data 
15 object including said data portion. 



52. The computer readable medium of claim 5 1 , wherein the 
transfer of data frames includes a data upload to the host device. 

53. The computer readable medium of claim 52, the instructions 
further comprising: 

write. a. particular data portion to a storage volume assigned to a 
particular identifier in response to receiving a data frame including the particular 
identifier and data portion, unique data objects being assigned to each storage 
volume. 
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54. The computer readable medium of claim 51, the instructions 
further comprising: 

receive a second frame from the client device requesting a second data 
transfer session; 

5 send a second frame to the client device defining a second session 

protocol that assigns an identifier to each data object of the second session; 

transfer a plurality of second data frames between the client and host 
devices, each second data frame including a second data portion and an identifier 
: assigned to a data object including the second data portion. 

10 55. The computer readable medium of claim 54, wherein the 

transfer of first and second data frames are interleaved. 

56. The computer readable medium of claim 54, wherein the 
transfers of second data frames are downloads from the host device. 

57. The computer readable medium of claim 51, the instructions 
15 further comprising: 

receive a frame from a second client device requesting a second data 
transfer session; 

send a frame to the second client device defining a second session 
protocol that assigns an identifier to each data object of the second session; and 
20 transfer a plurality of second data frames between the second client 

and host devices, each second data message including a data portion of a second 
data object and an identifier assigned to the second data object 
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58. The computer readable medium of claim 51, the instructions 
further comprising: 

send to the client device a routing for a handling program of assigned 
to each data object; and 
5 wherein each data frame includes the routing of the handling program 

assigned to the data object therein. 

59. The computer readable medium of claim 58, wherein first and 
second data objects are assigned first and second handling programs, respectively. 

60. The computer readable medium of claim 58, the instructions 
10 further comprising: 

write a particular data portion to a storage volume assigned to a 
particular identifier in response to receiving a data frame including the particular 
identifier and data portion, unique data objects being assigned to each storage 
volume; and 

15 control the write with the handling program assigned to the data object 

being written. 
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61. A computer readable medium encoding a program of 
instructions for transmitting data over a network between a host and client 
devices, the instructions comprising: 

receive from a client device a frame requesting one of a data upload 
5 session and a data download session; 

establish a session protocol in response to receiving the frame from the 
client device; 

transmit to the client device a frame defining the session protocol; 
receive from the client device a data frame conforming to the protocol 
10 if the frame from the client device requested an upload; and 

transmit to the client device a data frame conforming to the protocol if 
the frame from the client requested a download. 

62. The computer readable medium of claim 61, wherein the 
instruction to establish a session protocol assigns a handling program and a 
15 storage location to each data object identified in the frame requesting a session; 
and 

wherein the transmission to the client device of a frame defining the 
session protocol includes sending a routing for the handling program and an 
identifier for use by the handling program in determining the storage location 
20- assigned to each data object. 
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63. The computer readable medium of claim 61, wherein the 
transmission of a frame defining the session protocol includes a transmission of a 
size for data frames to the client device. 



64. The computer readable medium of claim 61, wherein the 
5 transmission of a frame defining a session protocol includes a transmission of a 
frame count, the frame count being the number of data frames that the client can 
send prior to receiving a request for more data. 



65. The computer readable medium of claim 61, 
wherein the transmission of a frame defining a session protocol 
10 includes a transmission of a format for a command to abort to the client device; 
and 

the instructions further comprise: 

terminate the session in response to receiving the command to abort 
from the client device. 

15 66. The computer readable medium of claim 61, wherein the 

transmission of a data frame comprises: 

an instruction to receive a frame including an identifier for 

determining a storage location, a routing of a handling program, and data to store 

in the determined storage location; and 
20 wherein the transmission of a session protocol includes transmitting to 

the client device the identifier and the routing of the handling program-assigned 

to each data object of the session. 
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67. The computer readable medium of claim 61, wherein the 
instruction to transmit a data frame further comprises: 

receive a second message including a second identifier for a second 
storage location and data to store in the second storage location; and 
5 wherein the transmission of a frame defining a session protocol 

includes a transmission of the second identifier to the client device. 



68. The computer readable medium of claim 61, wherein the 
instruction to establish assigns a storage location and associated identifier to each 
data object identified in the frame requesting a session. 

10 69. The computer readable medium of claim 68, wherein the data 

objects comprise: 

a first image file; and 
a second image file. 
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